Inside Macintosh: Open Transport /

Chapter 12 - Datagram Delivery Protocol (DDP)

Using DDP

To explicitly use DDP, you open and bind a DDP endpoint. You can then use that endpoint to send or receive data in discrete packets. For outgoing packets, DDP forms the packet header and hands the packet to the appropriate data link. For incoming packets, DDP examines the packet header and attempts to deliver any packet to the specified endpoint as long as the packet meets the following criteria:

• The destination address is valid.
• The default type of the packet matches that of the endpoint to which it
  is sent.
• The length of the packet matches the length specified in the packet header and does not exceed the maximum for a DDP packet.

If any of these conditions is not satisfied, DDP discards the packet without notifying either the sender or the receiver of the packet. In addition, DDP has no provision for requesting the sender to retransmit a lost or damaged packet.

Binding a DDP Endpoint

As with any endpoint, before you can use it to send or receive data, you must bind it to a physical address. The OTBind function takes three parameters: one that specifies the endpoint to be bound, one that requests a specific address, and one that returns the actual address to which Open Transport bound the endpoint.

When binding a DDP endpoint, you can request a particular DDP address, including a static socket address. You can also choose to only specify a DDP type for the endpoint, in which case you set the other fields of the DDP address structure to 0 and allow DDP to dynamically assign a socket. The chapter "AppleTalk Addressing" describes the different address formats you can use to specify an endpoint address.

When you bind a DDP endpoint, there are a few considerations to bear in mind. For example, you do not have to specify the endpoint's socket and the DDP type, but DDP behaves differently depending on whether you specify them or not. Highlighted here are the points to remember:

• If you bind without specifying a socket, DDP uses a dynamically assigned one; if you specify a socket, DDP tries to use it (a statically assigned socket).
• If you bind without specifying a DDP type or if you use a DDP type of 0, Open Transport sets the endpoint's DDP type to a value of 11. This gives you exclusive access to the socket, which means that no other endpoint can bind to it.
• If you bind using a specific DDP type, Open Transport sets the endpoint's DDP type to that value. Any other endpoint that you subsequently bind to that socket must have a unique nonzero DDP type.
• You cannot bind multiple ATP or DDP endpoints on the same socket, although you can bind multiple ADSP or PAP endpoints to the same socket because these endpoints use connection-oriented protocols.
• If you bind with a combined DDP-NBP address, Open Transport uses the DDP part of the address as described in the two preceding bullets. If the bind succeeds, Open Transport registers the NBP name on the endpoint's socket.
• If you bind with an NBP address only, there is no socket number in that form of address, so DDP uses a dynamically assigned socket. If the bind succeeds, DDP registers the endpoint's NBP name on that socket. The endpoint has no default DDP type, so Open Transport sets the DDP type to a value of 11. This has the same effect as described in the earlier bullets.

Using the DDP Type Field to Filter Packet Delivery

You can choose to filter your packet delivery service by using the DDP type field in the endpoint's DDP address structure. The DDP type field is ignored by all protocols other than DDP, so you do not specify the DDP type when passing an address to an AppleTalk endpoint for all protocol layers above DDP.

If you specify a valid nonzero DDP type value when you bind an endpoint, Open Transport uses that value as the default DDP type for that endpoint, using it on all packets sent from that endpoint. If you do not specify a DDP type value or use a value of 0, Open Transport uses a DDP type value of 11 as the default DDP type for that endpoint. If you specify a different DDP type value for any individual packet that you send, Open Transport overrides the endpoint's default DDP type and uses the packet's DDP type.

When receiving incoming packets, a specified DDP type works as a filter: you only receive packets of that one type. If, however, you bind an endpoint without a DDP type or with a DDP type of 0, you receive all incoming packets.

Using the DDP type field when you bind a DDP endpoint has special significance for both sending and receiving packets, as shown in Table 12-1.

Table 12-1 Effects of using the DDP type field

Task	A nonzero DDP type specified at bind	No DDP type or a DDP type of 0 specified at bind
Send	Open Transport uses this DDP type for outgoing packets unless you specify a different DDP type on a per packet basis.	Open Transport uses a DDP type of 11 for outgoing packets unless you specify a different DDP type on a per packet basis.
Receive	You only receive incoming packets for this DDP type.	You receive all incoming packets.

Using the Self-Send and Checksum Options

DDP has two options you can use to control the behavior of DDP endpoints: the OPT_SELFSEND and the OPT_CHECKSUM options.

You can use the OPT_SELFSEND option with DDP to turn self-sending on, which means that when you send a broadcast packet, you receive a copy of it at your sending endpoint. To turn this on, you set this option with a value of 1. By default this option is turned on.

When you use a DDP endpoint to send data, you can use the OPT_CHECKSUM option to enable the calculation of checksums on outgoing packets. In this case, when the packet is received, DDP calculates a checksum for the packet. If the calculated checksum does not match the packet's checksum, DDP assumes the packet has been corrupted and discards the packet without notifying its sender or receiver.

You can specify the OPT_CHECKSUM option on every call to OTSndUData and control the use of checksums on a per packet basis, or you can use the OTOptionManagement function to enable or disable checksums for all outgoing packets. The checksum option OPT_CHECKSUM can have one of two values: T_NO, which disables checksums, or T_YES, which enables it. By default this option is turned off.

For more information about using options, refer to the chapter "Option Management" in this book.

Using Echo Packets

You can use the AppleTalk Echo Protocol (AEP), a client of DDP, to measure the performance of an AppleTalk network or to test for the presence of a given node. Knowing the approximate speed at which an AppleTalk internet delivers packets is helpful in tuning the behavior of an application that uses a higher-level AppleTalk protocol, such as ATP and ADSP.

AEP is implemented in each node as a DDP client process referred to as the AEP Echoer. To use the AEP Echoer, you use the OTSndUData function to send a packet, called the echo request packet, to the target node, and you use the OTRcvUData function to receive a packet in response, called the echo reply packet.

AEP uses the statically assigned socket number 4, known as the echoer socket, to listen for echo packets. Whenever the endpoint associated with this socket receives a packet, AEP examines the packet's DDP type. A value of 4 identifies it as an AEP packet, and AEP then examines the first byte of the packet's data portion. A value of 1 identifies the packet as an echo request packet (sent out from your endpoint), and a value of 2 identifies the packet as an echo reply packet (returned to your endpoint from the remote node).

If the packet is an echo request packet, AEP changes this first byte to a value of 2 (an echo reply packet) before calling DDP to send the packet back to the socket from which it originated.

To test for the presence of a given node, you can iterate through a series of addresses --sending each several packets. If a node exists, AEP sends a packet back; if the node doesn't exist, no packet returns. Be sure to send each node address several packets in case one or more are lost in transmission.

To measure network performance, you need to know the round-trip time of a packet between two nodes on an AppleTalk internet. This is dependent on such factors as the network configuration, the number of routers and bridges that a packet must traverse, and the amount of traffic on the network. As these change, so does the packet transmission time. ATP protocol options let you specify retry-count and interval numbers whose optimum values you can better assess if you know the average round-trip time of a packet on your application's network.

Here are some general guidelines for using the AEP Echoer to measure network performance:

• Use the maximum packet size that you plan on using in your application.
• Accept only echo reply packets from the target node. Set the DDP type field of your endpoint to 4 to filter out all packets except for AEP packets.
• Send more than one packet and calculate the average round-trip time.

  Typically, you should receive an echo reply packet within a few milliseconds on a LAN and within a few seconds on a WAN. If you do not get a response after about 10 seconds, you can assume that DDP dropped or lost your echo request packet, and you can resend the packet.

  The echo reply packet contains the same data that you sent in the echo request packet. If you send multiple packets to determine an average turnaround time and to compensate for the possibility of lost or dropped packets, you should include different data in the data portion of each packet. This allows you to distinguish between replies to different request packets in the event that either some replies are not delivered in the same order that you sent them or that some packets are dropped.

• Bracket the code that sends and receives echo packets with a call to the Microseconds function. This function gives much better resolution than the TickCount function. The Microseconds function is documented in Inside Macintosh: Operating System Utilities.

Working With Multinodes

If you are using DDP, you can specify a multinode address for an endpoint. This allows you to bind endpoints to multiple node addresses on the same physical port, which can be useful for testing. Using only one physical machine, you can use multinode addressing to simulate multiple machines.

If a multinode client sends a broadcast or self-send packet, Open Transport makes copies of the packet for the other multinode clients on the same machine internally, thus reducing traffic on the network.

The significant fields for the multinode address format are the network number and node ID. You can request specific values for these address elements when you bind a multinode endpoint and the OTBind function returns the actual network and node values for the address to which Open Transport bound the endpoint. Multinode endpoints must use the DDP_OPT_SRCADDR option to specify the source DDP address for outgoing packets on a per-packet basis.

The DDP Source Address Option

DDP has one DDP-specific option, DDP_OPT_SRCADDR, which sets the source address for outgoing packets. This option is required for multinode endpoints, such as ARA, but can also be used with other types of endpoints.

The option's value must be a DDP address structure using the AF_ATALK_DDP address format. The source network number, node number, and source socket are taken from the DDP address. It is an error for these values to be illegal.

This option allows a multinode endpoint to tell Open Transport which of its several sockets actually sent the packet. If no socket is defined, Open Transport uses the default Socket 11.

Using General Open Transport Functions With DDP

This section describes any special considerations you must take into account for Open Transport functions when you use them with the Open Transport DDP implementation. For example, DDP only works with three of the Open Transport send and receive functions, OTSndUData, OTRcvUData, and OTRcvUErr because only these work with protocols that are connectionless and transactionless. You must be familiar with the function descriptions in the chapter "Endpoints" in this book before reading this section.

OTBind

The OTBind function associates a local protocol address with the endpoint you specify with the ref parameter. You can only bind one DDP or multinode endpoint to a single protocol address.

If you want to use the AEP Echoer, you must bind your endpoint with a socket number of 4 and a DDP Type of 4 to indicate that the endpoint is using the AEP implementation on the node.

OTSndUData

The OTSndUData function sends data through connectionless transactionless protocols.

If you want to use the AEP Echoer, you use this function to send echo packets. You need to set the first data byte to a value of 1 to indicate that it is an echo request packet.

OTRcvUData

The OTRcvUData function receives data through connectionless transactionless protocols.

If you want to use the AEP Echoer, you use this function to receive echo packets. The first data byte is set to a value of 2 to indicate that it is an echo reply packet.